%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Arquitetura IMS
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Arquitetura IMS}\label{cap:IMS}

  A arquitetura IMS define uma série de entidades e funcionalidades, cada uma
com responsabilidades bem definidas, \cite{TS23218}, \cite{TS23228},
\cite{TS24229}, \cite{3G-IMS}, \cite{3G-IMS-Concepts}, \cite{IMSAppServer} e
\cite{IMSNetArc}. A Figura \ref{fig:arquiteturaims} apresenta uma visão geral
dessa arquitetura. 

   \begin{figure}[ht]
     \centering
     \includegraphics[scale=0.7]{figuras/fig-ims-overview.png}
     \caption{Visão geral da arquitetura IMS \cite{IMSAppServer}}
     \label{fig:arquiteturaims}
   \end{figure}    

   A arquitetura é subdividida em três camadas principais: (i) camada de transporte,
responsável pela conectividade entre a rede IMS e os dispositivos e entre a rede IMS e
redes utilizando outras tecnologias; camada de controle, responsável pelo controle de
sessão e acesso aos serviços; e (iii) camada de serviço responsável pela execução dos
serviços móveis oferecidos pelos provedores. 

   Considerando os objetivos deste trabalho, serão detalhados apenas os
componentes e protocolos relacionados à camada de controle, mais especificamente os
componentes responsáveis pelo controle de sessão.


% Controle de Admissão
%
\section{Componentes de Controle de Sessão}

  O controle de sessão é parte fundamental da arquitetura IMS. O
componente responsável por essa tarefa é o CSCF, onde a troca de informações é
implementada através do protocolo SIP. Existem três tipos de componente CSCF, 
P-CSCF, S-CSCF e I-CSCF, cada um executando tarefas específicas, conforme
descrito a seguir. 

\begin{description}
  \item [Proxy-CSCF] - O P-CSCF é o primeiro ponto de contato entre um
terminal e uma rede IMS. Isso significa que toda requisição partindo de um UE
será enviado ao P-CSCF, assim como as mensagens de finalização partindo da rede
IMS. Existem quatro atividades designadas ao P-CSCF: 
\begin{enumerate}
 \item Compactação das mensagens SIP, uma vez que o SIP é um protocolo baseado
em texto com um número considerável de informações e parâmetros no cabeçalho.

 \item Associação de informações de segurança padrão IPSec.
 \item Interação com o componente de autorização de acesso \textit{Policy
Decision Function} (PDF)
 \item Detecção de chamadas emergenciais.
\end{enumerate}

  \item [Interrogate-CSCF ] O I-CSCF é o ponto de entrada para
chamadas executadas de redes externas. Ele é exposto através de \textit{Domain Naming
Service} (DNS), para que servidores remotos como um P-CSCF em um domínio de rede
visitado ou um S-CSCF em um domínio estrangeiro possam utilizá-lo como ponto de
entrada.

  \item [Serving-CSCF ] O S-CSCF é um servidor SIP que atua como um
servidor de registro (\textit{Registar Server}), tomando decisões de roteamento
de requisições, mantendo estado de sessão e armazenando informações de serviços
e usuários. Quando o usuário envia uma requisição de registro, a mensagem é
roteada para o S-CSCF o qual obtém as informações de autenticação. Após
o registro ser aceito, o S-CSCF obtém as informações do usuário associadas com
sua identidade pública, as quais serão utilizadas durante a manutenção da
sessão multimídia.

\end{description}

%
% Base de Dados e registro - HSS
%  
\section{Bases de dados de registro de usuário}

  Todos os dados dos usuários registrados são armazenados em um servidor
central chamado \textit{Home Subscriber Server} (HSS). O HSS armazena
informações de identificação, segurança e localização. Adicionalmente, o HSS
provê informações em qual S-CSCF o usuário está registrado.

  Em caso de haver necessidade de mais de um HSS, a arquitetura IMS prevê a
existência de um \textit{Subscription Locator Function} (SLF) para mapeamento de
informações de usuário e servidor HSS. Nesse caso, o SLF sabe informar em qual
HSS está armazenada a informação de um determinado usuário.

%
% Protocolos SIP e SDP
%
\section{Protocolos de Comunicação}

  SIP é um protocolo da camada de aplicação, utilizado para criar, modificar e
finalizar uma sessão (e.g chamada telefônica, distribuição de conteúdo
multimedia, etc.) entre um ou mais participantes \cite{rfc3261}. As principais
funções do protocolo SIP são, localização de dispositivos na rede, contactar
dispositivos para determinar as características de uma sessão multimídia, troca
de informações para o estabelecimento da sessão e gerenciamento de uma sessão em
curso.
  
   A especificação do protocolo SIP define um conjunto de entidades, conforme
mostra a Figura \ref{fig:arquiteturasip}:
UA, \textit{Location Server}(\textit{Registar}), \textit{Proxy Server} e
\textit{Redirect Server}. UAs são entidades lógicas que podem atuar como cliente
ou servidor; por exemplo, um dispositivo móvel é um UA cliente quando envia uma
requisição \texttt{INVITE} e um UA Servidor quando recebe uma requisição
\texttt{BYE}. \textit{Registrar Server} é a entidade que recebe as requisições
de registro de usuários e as armazena em um serviço de localização.
\textit{Proxy Server} é uma entidade intermediária responsável pelo roteamento
de requisições. Por fim, o \textit{Redirect Server} gera respostas direcionando
os clientes a contactarem URIs alternativas. 

  \begin{figure}[ht]
    \centering
    \includegraphics[scale=0.7]{figuras/fig-sip-overview.png}
    \caption{Visão Geral da arquitetura do protocolo SIP \cite{usingSIP}}
    \label{fig:arquiteturasip}
  \end{figure} 

  Além dos elementos físicos, o protocolo SIP oferece um conjunto de operações.

\begin{itemize}
  \item INVITE - utilizado para estabelecer sessão multimídia entre
duas UAs.
  \item REGISTER - utilizado pelo usuário para notificar a sua entrada
na rede com suas informações de localização.
  \item BYE - utilizado para encerrar uma sessão.
  \item ACK - utilizado para aceitar uma requisição de abertura de
sessão.
  \item CANCEL - utilizado para cancelar uma requisição de abertura de
sessão.
  \item OPTIONS - utilizado para consultar uma UA sobre sua capacidade
e disponibilidade.
\end{itemize}
   

  Em complemento ao protocolo SIP, o \textit{Internet Engineering Task Force} (IETF)
recomenda a utilização do protocolo SDP. O SDP é um protocolo da camada de aplicação
utilizado para descrever sessões multimídia, utilizando uma representação padronizada
\cite{rfc4566}.
    
  Uma mensagem SDP contém três níveis de informação, e aparecem na ordem
apresentada a seguir:
    
\begin{enumerate}
  \item \textit{Descrição de sessão} - inclui informações como
identificador de sessão, endereço IP, informações de contato, entre outros.
  \item \textit{Descrição de tempo } - informa sobre data/hora de
início e término da sessão.
  \item \textit{Formato e tipo de mídia} - informa sobre protocolo de
transporte utilizado, informações de conexão, largura de banda, chave de
criptografia, entre outros.
\end{enumerate}

As Tabelas \ref{tbl:sdp-sessao}, \ref{tbl:sdp-tempo} e \ref{tbl:sdp-midia}
resumem as informações contidas em uma mensagem SDP.
  
  \begin{table}[htbp]
    \centering
    \caption{Protocolo SDP - Descrição de Sessão}
    \label{tbl:sdp-sessao}
    \vspace{0.5cm}
    \hspace{0.5cm}
    \begin{tabular}{|c|l|}
      \hline \textbf{Atributo}	& \textbf{Descrição} \\
      \hline v=		& versão do protocolo \\
      \hline o=		& origem e ID da sessão \\
      \hline s=		& nome da sessáo \\
      \hline i=*	& informações \\
      \hline u=*	& URI \\
      \hline e=*	& endereço de e-mail \\
      \hline p=*	& número telefone \\
      \hline c=*	& informação de conecção \\
      \hline b=*	& zero ou mais informações de largura de banda \\
      \hline z=*	& time zone \\
      \hline k=*	& chave de criptografia \\
      \hline a=*	& zero ou mais linhas de descrição de mídia \\
      \hline
    \end{tabular}
  \end{table}
  
  \begin{table}[htbp]
    \centering
    \caption{Protocolo SDP - Descrição de Tempo}
    \label{tbl:sdp-tempo}
    \vspace{0.5cm}
    \hspace{0.5cm}
    \begin{tabular}{|c|l|}
      \hline \textbf{Atributo}	& \textbf{Descrição} \\
      \hline t=		& tempo de atividade da sessão \\
      \hline r=*	& zero ou mais repetições \\
      \hline
    \end{tabular}
  \end{table}
 
  \begin{table}[htbp]
    \centering
    \caption{Protocolo SDP - Descrição da Mídia}
    \label{tbl:sdp-midia}
    \vspace{0.5cm}
    \hspace{0.5cm}
    \begin{tabular}{|c|l|}
      \hline \textbf{Atributo}	& \textbf{Descrição} \\
      \hline m=		& endereço de transporte \\
      \hline i=*	& título \\
      \hline c=*	& informação de conexão \\
      \hline b=*	& largura de banda \\
      \hline k=*	& chave de criptografia \\
      \hline a=*	& zero ou mais linhas de descrição da mídia \\
      \hline
    \end{tabular}
  \end{table}


% % Tarifação e Cobrança
% %
% \subsection{Funções de Tarifação e Cobrança}
% 
%    Com as novas possibilidades de oferecimento de serviços e a presença de
%novos
% atores, os sistemas de cobrança assumem papel fundamental na arquitetura IMS.
% Nesse contexto, a arquitetura IMS oferece duas possibilidades, cobrança
%on-line
% e cobrança off-line.
%    
%    Na cobrança off-line, o principal componente é o \textit{Charging
% Collecton Function} (CCF). O CCF recebe informações de tarifação de todos os
% componentes IMS, utilizando como meio de comunicação o protocolo Diameter.
% Baseado nessas informações, são gerados os registros de cobrança,
% \textit{Charging Data Records} (CDR). A cada determinado período de tempo, os
% CDRs são processados pelo sistema de tarifação para geração da fatura do
% cliente.
%    
%    Na cobrança on-line, o processo fica um pouco mais complexo. A arquitetura
% IMS define dois componentes, o \textit{Event Charging Function} (ECF) para
% cobrança baseada em eventos e o \textit{Session Charging Function} (SCF) para
% cobrança baseada na sessão do usuário. 
%    
%    A cobrança baseada em sessão ocorre no momento do estabalecimento da
%sessão,
% verificando se o usuário tem crédito disponível, e durante uma sessão, a cada
% intervalo de tempo. Nesse modelo, o componente SCF recebe as informações do
% componente S-CSCF através do protocolo SIP.
%    
%    Na cobrança baseada em eventos, o ECF recebe informações dos componentes
% \textit{Media Resource Function Controller} (MRFC) e dos servidores de
% aplicação. Em ambos os casos, a comunicação é feita através
% do protocolo Diameter. Nesse contexto, um evento pode ser disparado, por
% exemplo, quando o usuário com uma sessão ativa, tentar acessar um serviço
% diferente. O ECF irá calcular o preço desse novo serviço e decidir se o
%usuário
% poderá acessá-lo ou não.
%    
%    Seja através do ECF ou do SCF, o cálculo do preço do serviço será feito por
% um componente de tarifação, \textit{Rating Function} (RF).
%    

\section{Requisitos}

   A arquitetura IMS foi definida com base nos requisitos arquiteturais definidos em
\cite{TS23221}.

\begin{enumerate}
  \item Conectividade através de redes IP (IPv4 e IPv6)
  \item Independência de acesso
  \item Qualidade de serviço - \textit{Quality of Service} (QoS) - no acesso a serviços
  \item Comunicação segurança
  \item Suporte a \textit{roaming}
  \item Integração com outras tecnologias
  \item Estilo arquitetural baseado em camadas
\end{enumerate}

   Adicionalmente, \cite{IMSScalabilityIssues} apresenta alguns requisitos de
escalabilidade que devem ser considerados nos projetos de rede IMS.

   O protocolo SIP é o elemento chave para possibilitar comunicação em redes IMS. Através
do SIP, usuários podem estabelecer comunicação independente do tipo de conteúdo e número
de participantes, além da heterogeneidade de dispositivos, tais como telefones celulares,
computadores, TV digital, entre outros. 

   Conforme já mencionado, um dos principais problemas de comunicação é a
descoberta do nó na qual um usuário será encontrado. O protocolo SIP endereça
essa questão através do mapeamento entre AoR e URI de contato do usuário. Na
arquitetura padrão do SIP, o elemento responsável por esse mapeamento é o
Servidor de Registro, um elemento totalmente centralizado. 


   Nesse sentido, considerando a perspectiva de demanda crescente por serviços baseados em
IMS, um protocolo com característica centralizada, tal como o SIP, poderá inviabilizar o
acesso ubíquo à Internet proposto pelo 3GPP. 

   \section{Considerações}

   A arquitetura IMS apresenta uma série de entidades, funcionalidades e protocolos com
responsabilidades bem definidas. No entanto, é importante ressaltar que a arquitetura IMS
é agnóstica em termos de implementação, ou seja, ela \textbf{define O QUE} é necessário em
termos de elementos e funcionalidades, e quais protocolos devem ser utilizados,
\textbf{mas não diz COMO} devem ser implementados.

   O principal problema é que as implementações tendem a seguir à risca o modelo
arquitetural proposto, o que torna a arquitetura IMS centralizada e com os problemas de
desempenho apresentados anteriormente.

   Nesse sentido, cabe a definição de uma arquitetura de implementação descentralizada e
escalável, e não a mudança da arquitetura IMS.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Espaço de Tuplas
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Espaço de Tuplas}\label{cap:TS}


\section{Fundamentos de Espaço de Tuplas e a linguagem Linda}

  O conceito inicial de espaço de tuplas foi proposta por David Gelernter em meados dos
anos 80, a partir do desenvolvimento da linguagem Linda
\cite{GenerativeComm,LindaContext}.

  A linguagem Linda implementa o modelo de programação paralela denominado
\textit{Generative Communication}\footnote{Ao longo do texto, esse termo não
será traduzido}, e foi desenvolvida tendo como base o paradigma de Memória
Associativa\footnote{Memória que é endereçada em função do conteúdo, tendo uma
valor associado a uma chave.}

  O modelo \textit{Generative Communication} surgiu como uma alternativa aos
três principais modelos existentes à época, variáveis compartilhadas
(\textit{shared memory}), passagem de mensagem (\textit{message passing}) e
operações remotas (\textit{remote operations}). A principal diferença do
modelo generativo é o desacoplamento entre processos
\cite{LindaHeterogeneousEnv}. Isso ocorre em função da natureza de comunicação
indireta entre processos, ao contrário dos três modelos apresentados
anteriormente, onde a comunicação entre processos ocorre de maneira direta. Isso
significa dizer que se dois processos precisam se comunicar, eles não trocam
mensagens ou compartilham variáveis; em vez disso, o processo produtor insere
uma tupla no espaço, e o processo consumidor consome a tupla do espaço
\cite{LindaContext}.

  De maneira geral, podemos considerar um espaço de tuplas como sedo um "saco" de tuplas
onde
qualquer máquina pertencente a um \textit{cluster} pode realizar operações,
sejam operações síncronas ou assíncronas. Formalmente, um espaço de tuplas é caracterizado
como uma abstração de um ambiente computacional baseado no conceito de uma única
memória virtual compartilhada, responsável por armazenar as tuplas a serem
processadas. Suponhamos a existência de dois processos, P1 e P2 e um espaço de
tuplas T1; para enviar dados a P2, o processo P1 gera tuplas e as coloca em T1;
para consumir a tupla gerada por P1, o processo P2 faz acesso ao espaço T1 e
recupera a tupla.

Existem dois tipos de túplas, tuplas de processos (\textit{process tuples}) e
tuplas de dados (\textit{data tuples}). As tuplas de processos referem-se às
tarefas em execução; estas, trocam dados gerando e consumindos as túplas de
dados. As túplas de dados são estruturas de dados formadas por uma coleção de
dados (atributos) de tipos distintos. Essa estrutura pode ser associada
facilmente a objetos de linguagens Orientadas a Objetos como Java/C++ ou a
estruturas (\textit{struct}) da linguagem C.

Existem três operações fundamentais que podem ser executadas em um espaço de tuplas,
\textit{out()}, \textit{in()} e \textit{read()}. Tais operações devem ser
executadas de forma atômica.

\begin{enumerate}
	\item out(): A operação \textit{out} pode ser formalizada como sendo:
			\begin{equation}
				\textit{out(N, P2,...Pn})
			\end{equation}
	onde, \texttt{P2,..,Pn} é uma lista de parâmetros que podem ou não ter
valor, e \texttt{N} é a chave que identifica a tupla no espaço. A execução da
operação \textit{out} causa inserção da tupla em um espaço de tuplas. \\
	
	\item in(): A operação \textit{in}, semelhante à operação \textit{out},
é formalizada como sendo:
			\begin{equation}
				\textit{in(N, P2,...Pn})
			\end{equation}
	onde, \texttt{P2,..,Pn} é uma lista de parâmetros que podem ou não ter
valor, e \texttt{N} é a chave que identifica a túpla no espaço. Se a tupla
\texttt{N} existir no espaço, esta será removida e o processo continua. Caso não
exista a tupla \texttt{N} no espaço, o processo será suspenso até que uma tupla
seja incluída. \\
				
	\item read(): A operação \textit{read} é identica à operação
\textit{in}, exceto pelo fato de que a execução desta operação não remove a
tupla do espaço.
	
\end{enumerate}

  As operações de leitura (e.g \textit{in(..)} e \textit{read(..)})
realizadas no espaço podem utilizar o conceito de \textit{match}. Nesse caso, um
processo consumidor lê as tuplas de acordo com critérios passados na operação de
leitura. Por exemplo, a execução da operação \texttt{in("a string", ?f, ?i, "b
string")} causa uma busca no espaço por tuplas de quatro elementos; o primeiro
\texttt{"a string"} e o último \texttt{"b string"}, e os dois parâmetros do meio
como variáveis \texttt{f} e \texttt{i}. Caso não exista nenhuma tupla no espaço
com as características informadas, a operação \textit{in(..)} é bloqueada até
aparecer uma tupla \cite{LindaContext}.

\section{JavaSpace\texttrademark}

	Após a popularização da linguagem Linda no meio acadêmico nos anos 80, o espaço de
tuplas ficou esquecida, ressurgindo no final dos anos 90 com a especificação
JavaSpaces\texttrademark pela Sun Microsystems, \cite{LindaJava} \cite{JavaSpacesBook},
com o aval da equipe responsável pela linguagem Linda da Universidade de Yale. A
especificação JavaSpaces\texttrademark foi produzida pela Sun como parte do projeto Jini
\cite{Jini}.
	
	JavaSpaces\texttrademark é uma especificação para implementação de
aplicações distribuídas, baseada em espaço de tupla \cite{JavaSpacesBook}.
Diferente dos tradicionais modelos de programação distribuída
baseados em passagem de mensagem ou RMI, o modelo do \textit{JavaSpaces} utiliza
uma coleção de processos que cooperam através de fluxos de objetos que são
inseridos/removidos de um ou mais espaço, conforme
mostra a Figura \ref{fig:javaspaces}.
	
\begin{figure}[ht]
	\centering
	\includegraphics[scale=0.5]{figuras/fig-javaspaces.png}
	\caption{Visão geral do JavaSpaces\texttrademark \cite{JavaSpacesBook}}
	\label{fig:javaspaces}
\end{figure}

Assim como na especificação básica da linguagem Linda, os objetos não se
comunicam diretamente. Aplicações e processos interagem com o espaço através de
um conjunto simples contendo quatro operações: 

\begin{enumerate}
	\item \textit{write()} Insere objetos no espaço
	\item \textit{take()} Recupera objetos do espaço. Existe uma variante
desta operaçõa chamada \textit{takeIfExists()}.
	\item \textit{read()} Lê objetos do espaço, sem removê-los. Também
possui uma variante chamada \textit{readIfExists()}.
	\item \textit{notify()} Notifica um objeto específico quando tuplas
inseridas no espaço atendem a um determinado critério.
\end{enumerate}

  É importante notar que processos não modificam objetos no espaço ou acessam
seus
métodos diretamente. Para tal, um processo precisa recuperar um objeto do espaço
através das operações \textit{take()} ou \textit{read()} e, se necessário,
inserí-lo novamente no espaço.

  Para que um objeto Java se torne uma tupla, é necessário implementar a
interface \texttt{net.jini.core.entry.Entry} disponibilizada pela especificação
Jini\texttrademark \cite{Jini}, conforme o fragmento de código a seguir.

\begin{verbatim}
  public class EntryImpl implements Entry {
    public String nome;
    public String id;
    public DummyEntry() {
    }
    public DummyEntry(String nome) {
        this.nome = nome;
    }
  }
\end{verbatim}

O código a seguir ilustra algumas operações no espaço.
\begin{verbatim}
1   Entry template = new EntryImpl("Hello Word");
2   Transaction.Created myTxnC = TransactionFactory.create(theTxnMgr, 5000);
3   Transaction myTxn = myTxnC.transaction;

   // tenta obter uma tupla do espaco baseado no template
6   Entry tupla = space.take(template, myTxn, timeout);
7   if (tupla != null) {
        // faz alguma coisa           	
        // devolve tupla para o espaco
10        space.write(myResult, myTxn, Lease.FOREVER);
11   }
12   myTxn.commit();
\end{verbatim}

Conforme observado, inicialmente um template de um objeto \texttt{Entry} é
criado com o nome "Hello Word" (linha 1). A operação \textit{take(..)} recupera
uma tupla do espaço baseado no template cujo nome é "Hello Word" (linha 6). Se
existir uma tupla, pode-se realizar operações sobre essa tupla; após o
processamento a tupla é devolvida no espaço através da operação
\textit{write(..)} (linha 10).

\section{L\ensuremath{^{2}}imbo}

  Em \cite{l2imbo}, foi proposta uma plataforma para aplicações móveis
distribuídas chamada L\ensuremath{^{2}}imbo. 

  A plataforma L\ensuremath{^{2}}imbo apresenta uma série de extensões em
relação ao modelo original proposto na linguagem Linda. Sua principal
característica é a definição de múltiplos protocolos para implementação de
espaço de tuplas, cada um deles responsável pela implementação adequada das
operações passíveis de utilização na plataforma, e.g. \textit{in} (inclusão),
\textit{out} (remoção) e \textit{rd} (leitura). Os protocolos são classificados
como Distribuído, Centralizado e Local, conforme a Figura  \ref{fig:L2imboArch}.

  \begin{figure}[ht]
    \centering
    \includegraphics[scale=0.3]{figuras/fig-L2imboProtocol.png}
    \caption{Arquitetura L\ensuremath{^{2}}imbo}
    \label{fig:L2imboArch}
  \end{figure}


  \begin{description}

    \item[Distribuído - \textit{Distributed Tuple Space} (DTS)] Projetado para
oferecer escalabilidade e maximizar a disponibilidade de tuplas em aplicações
distribuídas. Apesar dessa característica ser a base do conceito de espaço de tuplas, a
novidade na plataforma L\ensuremath{^{2}}imbo, pelo menos à época em que foi
criado, é o fato de existir uma mecanismos para garantir a retirada única de
tuplas do espaço, ou seja, apesar da tupla estar replicada em diversos servidores, será
lida apenas por um deles.

    \item[Centralizado - \textit{Centralized Tuple Space} (CTS)] Em contraste ao
modelo Distribuído, no modelo Centralizado um dos nós é escolhido para armazenar
as tuplas. Os outros nós utilizam um mecanismo de acesso ao CTS para ler e
gravar tuplas.

    \item[Local - \textit{Local Tuple Space} (LTS)] O modelo Local é o mais
simples de todos. Cada nó possui um espaço de tupla local. Nesse modelo não
existe acesso à rede. O objetivo do LTS é compartilhar informações entre
aplicações localizadas em um mesmo nó.

  \end{description}

  A interface de programação da plataforma L\ensuremath{^{2}}imbo segue o
padrão original da API Linda, com algumas extensões.


\section{Lime e LighTS}

  Lime (Linda In a Mobile Environment), \cite{lime}, criou uma nova abordagem
para desenvolvimento de aplicações móveis baseadas em espaço de tuplas. O
modelo proposto no Lime assume um conjunto de nós denominados \textit{containers}, onde
agentes são executados. Os agentes podem se mover de um nó para outro. 

  Cada agente pode possuir múltiplos espaços de tuplas, que por sua vez, podem
ser compartilhados com outros agentes em uma mesma faixa de comunicação.

  A interface de programação do Lime segue o mesmo padrão definido pelo modelo
proposta inicialmente em Linda, porém, as operações extendem o modelo original
acrescentando um parâmetro representando o identificador do agente responsável
por receber a tupla.

  LighTS, \cite{lights}, é um \textit{framework} que pode ser utilizado como base para o
desenvolvimento de aplicações baseadas em espaço de tuplas. Ele não é um espaço
de tupla propriamente dito, e sim um conjunto de elementos (objetos Java) que
podem ser implementados ou estendidos. 

  Inicialmente, o LighTS foi desenvolvido para ser o núcleo do Lime, porém,
percebeu-se que ele pode ser utilizado em outros modelos de espaço de tuplas.
As principais interfaces oferecidas pelo LighTS são \texttt{ITupleSpace},
\texttt{ITuple} e \texttt{IField}, representadas a seguir.

\begin{verbatim}
  public interface ITupleSpace {
    String getName ();
    void out ( ITuple tuple );
    void outg ( ITuple [] tuples );
    ITuple in ( ITuple template );
    ITuple inp ( ITuple template );
    ITuple [] ing ( ITuple template );
    ITuple rd ( ITuple template );
    ITuple rdp ( ITuple template );
    ITuple [] rdg ( ITuple template );
    int count ( ITuple template );
  }

  public interface ITuple {
    ITuple add ( IField field );
    ITuple set ( IField field , int index );
    IField get ( int index );
    ITuple insertAt ( IField field , int index );
    ITuple removeAt ( int index );
    IField [] getFields ();
    int length ();
    boolean matches ( ITuple tuple );
  }

  public interface IField {
    Class getType ();
    IField setType ( Class classObj );
    boolean matches ( IField field );
  }

\end{verbatim}

\section{Considerações}

   Este capítulo apresentou os conceitos fundamentais do paradigma de espaço de tuplas.

   O modelo de sistema distribuído baseado em espaço de tuplas surgiu como uma alternativa
aos três principais modelos existentes na época, variáveis compartilhadas (\textit{shared
memory}), passagem de mensagem (\textit{message passing}) e operações remotas
(\textit{remote operations}). A principal diferença é o desacoplamento entre processos,
obtido em função da natureza de comunicação indireta, ao contrário dos modelos
tradicionais, onde a comunicação entre processos ocorre de maneira direta. 

   Existem várias pesquisas acadêmicas propondo modelos de implementação de espaço de
tuplas. Conforme será apresentado mais adiante, para este trabalho foi adotada a
abordagem de espaço de tuplas sobre redes P2P, mantendo a semântica da linguagem Linda.

